Revisiting optimistic and pessimistic concurrency control

Optimistic concurrency control relies on end-of-transaction validation rather than lock acquisition prior to data accesses. Optimistic concurrency control is popular and various systems employ it based on a conviction that it increases concurrency, performance, and scalability. In contrast, we have concluded that optimistic concurrency control permits more concurrency than pessimistic concurrency control only if it fails to detect some actual conflicts or if a particular implementation of locking detects false conflicts. An example of the former is a weak transaction isolation level, e.g., “repeatable read” instead of “re-peatable count,” i.e., serializability. An example of the latter is an unnecessarily coarse granularity of locking, e.g., traditional key-value locking. Another example of the latter is unnecessarily long lock retention, e.g., while writing a commit log record to stable storage in order to ensure a transaction’s durability. A fair comparison of alternative techniques requires equal criteria (e.g., serializability) and equal opportunities (e.g., in terms of granularity of concurrency control, access modes, etc.). In such a comparison, the crucial differences are the timing of conflict detection and the options for conflict resolution. For example, if a conflict between two transactions is found after one of them is already committed, failing the other transaction seems the only recourse. With these issues properly addressed and exploited, pessimistic concurrency control will always match or out-perform optimistic concurrency control. For the time being, this analysis focuses on single-version storage and ignores distributed transactions. External Posting Date: May 26, 2016 [Fulltext] Internal Posting Date: May 26, 2016 [Fulltext]  Copyright 2016 Hewlett Packard Enterprise Development LP